(レポート) ユーザー企業に学ぶビッグデータ分析基盤活用実践セミナー〜Amazon Redshift で短期間導入・低コスト運用〜

はじめに

本記事は2016年9月27日(火)に開催した「ユーザー企業に学ぶビッグデータ分析基盤活用実践セミナー〜Amazon Redshift で短期間導入・低コスト運用〜」のレポートです。

会場はアマゾンウェブサービス株式会社様。

レポート

AWSを使ったビッグデータ活用とサービスの紹介

スピーカーはアマゾン ウェブ サービス ジャパン株式会社　相澤 恵奏 氏。

はじめに

・今DWHを使っている人？→数名。

・分析DBの歴史
　・1974年、Ingresがリリースされたのが仕組み。
　・PostgreSQLが出てきたのが1989年。
　・SybaseIQのリリースが1999年。
　・2000年、InfiniDBがリリース。会社が倒産して現在はOSSに。
　・2012年、Amazon Redshiftがリリース。
　・その後様々な買収が続いて整理。
・DWHの時代による遷移
　・OLTP向けRDBMS→データが増えれば増えるほどI/Oがネックになる。
　・DWHアプライアンス→速くはなるけど効果になる。
　・ソフトウェア分析基盤→列指向と超並列アーキテクチャ(MPP)
　・Redshift→フルマネージド、初期投資不要、列指向でMPP。

Amazon Web Services

・Amazonのビジネス(Amazon.co.jp)の基幹システムを支える技術。
・商戦のピークに合わせてサーバを増減させて無駄を減らす。
・使いたい時に使いたいだけサーバを支えるサービスを提供。
・クラウドのインパクトを歴史上に例えると...
　・発電機所有が差別化要因だった時代...
　　・中央発電所+送電線がパラダイムシフトに。
　　・いつでも必要なだけ安価に使えるように。
　・同じことがクラウドでも言える。
　　・発電機を持つことが差別化要因では無くなった。
　　・電気を利用して何を創造するかが差別化要因に。
　　・インフラを持つのではなく、インフラで何を創造するのか。
・AWSの歴史。
　・2006年、S3とEC2がリリース。
　・2009年、VPCがリリース。
　・2011年、東京リージョンが開設。国内での利用が伸びた。
　・現在は世界13箇所のリージョン、50以上のエッジロケーション、70を超えるサービスを提供。
・クラウドコンピューティグとは？
　・初期投資不要→すぐに使える。
　・完全従量課金→使った分だけ課金。
　・柔軟なキャパシティ→不要になれば廃棄。
　・市場投入スピード→どんどん新サービスをリリース。
　・セキュア→個人情報、金融情報もクラウドで利用。
　・グローバル展開→世界中にリージョンを提供。
・日本で数万以上のお客様、世界で100万以上のお客様に使って頂いている。
・AWSを軸にした新たなエコシステム。
　・APNパートナーがどんどん増えている。
・AWSのインフラサービス
　・必要なサービスを望むように構築できる。
　・オンプレミスのナレッジをそのまま持っていける。フォークリフトのように。
・AWSのマネージドサービス
　・管理運用はAWS、お客様は運用不要で機能だけ使う。
　・マネージドサービスを活用してアプリケーション作成に注力できる。
　・データ分析で使うマネージド・サービス。収集、保存、分析、可視化。

Amazon Redshift

・クラウド上のデータウェアハウス。
・ペタバイト級までスケールアウト可能。
・フルマネージドサービス。
・高い汎用性。
　・PostgreSQLと互換性が高く、現在のツールをそのまま使うことが出来る。
・高いパフォーマンス。
・Redshiftの構成。
　・データはCompute Nodeに分散される。
　・SQLの実行はLeader Node経由で対象のCompute Nodeに振り分けられる。
　・パフォーマンスの上げ方。
　　・Compute Nodeを増やせばその分各ノードのデータ所持量が減り、速くなる。
・I/O削減
　・列指向型(カラムナ)
　　・DWH用とに適した格納方法。
　　・行指向だとデータが増えるとその分遅くなる。
　　・列指向であれば列の集計や検索が速くなる。
　・圧縮
　　・ユーザーが意識することなく、自動的にデータ圧縮。
　・ゾーンマップ
　　・ブロック単位でディスクにデータを格納。
　　・ブロック内の最小値と最大値をメモリに保存。
　　・不要なブロックを読み飛ばすことが可能。
・フルマネージドサービス。
　・マネージドコンソールでモニタリング可能。
　・構成変更も簡単、アジリティが高い。
・一般的な構成例
　・プライベートネットワークを構築、VPNやDirectConnectで既存システムと接続。
　・データをS3に保存、Redshiftに一括ロード
　　・1行ずつの処理より一括ロードのほうがRedshift向き。
　・任意の分析ツールで分k性。
・事例。
　・NTTドコモ様。ペタバイト以上のデータをRedshiftで運用。セキュリティも改善。
　・Amazon.com。Oracle RACからのリプレース。データロードとクエリパフォーマンスを改善。
　・すかいらーく様。Redshiftを使った分析基盤を1ヶ月で構築。すぐ構築出来る良い例。
・Redshiftへの移行例。
　・新規のDWHをスモールスタート。
　　・良い結果が出たら継続、ダメなら仕切り直し。試せるというのがクラウドの最大の特徴。
　・上手くいったら既存DWHとRedshift両方にデータを投入。
　・最終的に既存DWHを廃棄。

まとめ

・Redshiftを含めAWSには70以上のサービスがある。
・必要なときに必要なだけ支える。
・Redshiftはフルマネージド、従量課金、列指向、MPP。

ビッグデータ分析基盤導入事例

スピーカーは株式会社ダーツライブ マーケティング室 室長 大川 智行 氏。

はじめに

・株式会社ダーツライブのご紹介。
　・コミュニティエンターテイメント企業。
　・エレクトリックダーツDARTSLIVEの製造をしている会社。
　・ダーツ機を作るだけでなく、オンラインで対戦やコミュニケーションをする仕組みを提供。
　・ダーツグッズの販売やプロイベントの開催を実施。
　・サービス開始は2003年、10年以上。
　・世界17カ国でグローバルにサービス展開。
・家庭用ダーツも作っている。
　・Amazon.co.jpで販売している。
　・Bluetoothでスマホと連携。

ビッグデータ分析基盤の導入

・導入前の課題や要望
　・以前からデータ活用している業務はあった。
　　・A/Bテストしたり、プロモーション効果測定など。
　・利用しているデータが属人化、ブラックボックスに。
　・KPIで膨大なExcel資料を作成していた。
　・情報に簡単にアクセスしたい。
　・データ抽出作業をする担当者の負荷を減らしたい。
　・ダッシュボードが分かりづらいので改善したい。
　・データを見て判断する現場の人間が情報にアクセスできるようにしたい。

・システム構成
　・データ置き場はS3。CSVを配置。全社的に共通化。
　・ロードや集計はEC2上にタスクスケジューラとJavaアプリ。
　・DWHはRedshift。
　・BIをExcelからTableau DesktopとTableau Onlineに。
　　・Tableauのビューが担当者PCに溜まらないようにOnlineで共通化。
　・構成図。
　　・本社ネットワークとAWSをDirect Connectで接続。

・なぜRedshiftなのか。
　・フルマネージドサービス。メンテナンスする人手がいらない。
　　・マーケティング部門は施策や開発に人手を集中しているため。
　・段階的な料金設定。
　　・スモールスタートで始められる。
　　・予算確保の理由として、「まず試してみる」から始められた。
　・AWSサービスとの連携。
　　・以前より使っていたS3をそのまま使える。
　　・情報システム部門でもAWSを使っていた。

・クラスメソッドに相談した理由。
　・デジタルマーケティングについての圧倒的な事例実績。
　　・デジタルマーケティングの分野でクラスメソッドの名前を見ることが多かった。
　・AWSプレミアコンサルティングパートナーという実績。
　　・AWSとのコネクションが太い。
　　・AWSの新しいサービスリリースをキャッチアップして届けてくれる。
　・ブログによる情報発信の多さ、最新技術の発信。
　・エンジニアのアンテナの高さ。

・システムのポイント。
　・既存システムとの疎結合。
　　・データをとりあえずS3に置ければ、他部門との調整が最小化出来る。
　・結合したマスターデータを用意。
　　・バラバラのデータを結合してRedshiftに投入。
　　・分析する人が理解しやすいようにマスタデータ構造を設計。
　・担当者のスキルに合わせた使い分け。
　　・DB構成を把握しているデータ担当者はTableau Desktopを使って自分で好きに利用。
　　・データ担当者以外はTableau Onlineにデータソースを用意。
　　　・データ担当者がRedshift上にデータを加工して用意。
　　　・技術的なことを知らなくても簡単にデータにアクセス、分析できる。

・開発作業の進め方
　・開発期間は3ヶ月。
　・クラスメソッドとの作業連携はBacklogを利用。
　　・チケット数は3ヶ月間で70弱。
　・2週間に1回、プロジェクトミーティングを実施。
　　・技術的な課題や要望を口頭で相談。
　・ダーツライブ側のプロジェクトメンバーは3人。

・運用保守
　・監視、1次対応はクラスメソッドのサービス「くらもん」を利用。
　　・監視部分をまるっとお任せ。
　・運用と活用
　　・マーケティング部門内にメンバーを用意。
　　・各部門がセルフBI出来るように、部門ごとに数名の担当者を用意。
　・格納データ量
　　・数十億レコード。Redshiftに格納出来るデータ量としてはまだまだいける。

・解決、達成。
　・Redshiftに常に新鮮なデータがある状態。
　　・これまでは月締めなど、最新のデータが見れない状況だった。
　　・デイリーでデータ処理、すぐにデータが確認できることで、ストレスがなくなった。
　・作業時間の短縮。
　　・ノウハウが集積、一度作ったレポートはすぐ出せるように。
　　・パフォーマンス向上により集計が即時可能、レポーティングもすぐに可能。
　　・これまでマンスリーでやっていたような処理を簡単に実行できるようになった。
　・エンジニアでなくても使いやすい。
　　・Tableauを繋げてしまえば誰でもすぐに使える。
　　・BIツールのパフォーマンスが悪いとビジュアライズがなかなか出来ない。
　　　・Redshiftなら分析軸をすぐに変えて確認できる。
　　・どうしてもクエリを直接実行したい場合はAginity Workbench for Redshiftを利用。

・ランニング費用。
　・リザーブドインスタンスによる年間契約。
　　・EC2、Redshift、ともに前払い。
　　・年$5200くらい。
　・EC2、S3、DirectConnectなどの月額費用。
　　・月$120くらい。
　・どちらもミニマムスタート分の費用という認識。しばらくはこのままで問題なし。

・今後の活用。
　・データの収集対象を広げる。
　　・今回は元々あったDWHで使っていたデータの移行。
　　・データ構造のナレッジを共有。海外利用も広げたい。
　・データドリブン、セルフBIの啓蒙。
　　・社内勉強会の開催、各部が積極的に使ってくれるように。
　　・ITザビエル、利用を周りに周知して啓蒙活動。
　・経営層、営業向けだけでなく、事業部門での利用を推進。
　　・マーケティングデータの強化。
　・マーケティングオートメーションなどの施策展開。

最後に

・データ分析環境が欲しいけど大きな予算がない。
　・スモールスタート、まずはやってみる。
・今やっている集計に時間がかかる。
　・BIの要求するレスポンスに耐えられるパフォーマンス。
・システムに詳しい担当者がいない。
　・クラスメソッドがしっかりサポート。

メンバーズ、CS・データおよびアナリティクスの紹介と簡単な分析デモ

スピーカーはクラスメソッド株式会社の甲木 洋介。

はじめに

・AWS総合支援サービスメンバーズの紹介。

スモールスタート

・分析したいテーマがあること。
　・データがあっても分析は出来ない。データを集めただけでは分析結果は現れない。
　　・何をしたいのかを明確に持つ。
・分析できるデータがあること
　・データの構造を把握。データの不足を確認。何が足りていて何が足りないのか。
　・目標を持って、必要なデータを持ってくる。
　・自動連携は後回しでも良い。
・分析のためのツールが用意できること。
　・データベース管理サービスとBIツール。
　・少人数で大量の集計をするならカラム型。
　　・Redshiftは深い検索、大量のデータ取得は得意。
　　・ピンポイントに1行のデータを取得するのはRedshiftは苦手。
　　・用途に応じて使い分ける。
　・安く早くいつでも止めれるのはクラウドサービス利用。
　・BIツールは帳票なのかグラフなのかで洗濯。
　・ETLの仕組みを検討。
　　・cron+スクリプトが安く堅実。
　　・スケジューリングやエラーハンドリングが必要な場合は専用ツール。
　　・手作り工数と予算の兼ね合い。

データ分析を始める流れ

・データ準備
　・基幹系から特定データを抜き出し。
　　・自動抽出は後で良い。
　・マスタ系は全件洗い替えも検討。
　・経験上はタブ区切り。
　　・CSVは個別実装が多くて困ることが多い。囲み文字はないほうが楽。
　・文字コードは統一。
　　・RedshiftはUTF-8のみ対応。
　・データ型は可能な限り把握しておく。
　・巨大なデータはファイル名の接頭句を統一して細かく分けておく。
　　・スライスの分だけファイルを分解しておく。
　　・各ファイルはgzipなどで圧縮しておくのが望ましい。
・データ蓄積
　・S3に保存しておくのが望ましい。
　　・S3は安い。DBに入れるより安価に長期間保存可能。
　　・ETLツールを使うか、安価にaws cliにて実行。
　　・ファイルをディレクトリで保存する場合にはシステム名/テーブル名/日付がお勧め。指定しやすい。
・データベース管理サービス(Redshift)準備
　・余裕を持って構成。
　　・時間単位で切り替えられるので最初は贅沢に。
・データロード・集計
　・事前にデータの形でテーブルを作っておいてインサートするのがベスト。
　・必要な加工をするためのスキーマを別途作成。
・Redshiftクラスタ起動前に必要な設定
　・VPCなどのネットワーク関連
　・IAMなどセキュリティ関連
・デモ

ビッグデータ案件の進め方

・チューニングテクニックで必ず性能が上がるとは限らない。
・まずはインスタンスタイプをあげて力ずくで性能目標をクリアさせる。
・その後チューニングでさらに性能を上げる。
・チューニングをやりきったら目標担保できるところまでインスタンスタイプを下げる。
・チューニングより構成変更。

さいごに

たくさんの皆様にご参加頂きました。ありがとうございました。またこのようなセミナーを開催していきますので、どうぞよろしくお願い致します！